Electronic commerce (“E-Commerce”) is a distributed computing environment with dynamic relationships among a large number of autonomous service requesters, brokers and providers. In recent years, there has been much interest in the use of software agent technology to support the automation of E-Commerce. A world is envisioned where tasks that are normally performed by individuals are handled automatically by software agents. Examples of such tasks found in a company may include finding a suitable product for purchase, generating requests of quotes, negotiating price of the product, generating purchase orders, responding to requests for quotes, processing payment information, and shipping the product.
Most electronic commerce (E-Commerce) applications are based on business partnerships between different enterprises. Consequently, one important and necessary component to enable the automation of electronic commerce is a mechanism for supporting and facilitating the cooperation and collaboration between different parties (e.g., partners) in different enterprises.
There are several different prior art approaches for supporting a business process between two parties in different enterprises. A first prior art approach employs a central coordinator model. In this model, the execution of a business process has only one process instance that is handled by a central server (e.g., a central workflow engine). In other words, this coordination model employs a centralized coordinator or server to manage the interaction between agents. A business process typically has a plurality of tasks. Although tasks can be distributed among different agents, a central server manages the entire process.
Unfortunately, the central coordinator model is not suited for business processes that involve parties in different enterprises (i.e., inter-enterprise business collaboration). One reason that the central coordinator model is not suited for interaction across enterprises is that the central coordinator model has been designed and tailored for facilitating cooperation between agents that are in the same enterprise (i.e., intra-enterprise cooperation). Consequently, issues particular to cooperation between two different enterprises are not addressed by this approach.
As noted previously, most E-Commerce applications are based on inter-enterprise business partnerships, where parties across enterprise boundaries are unlikely to be organized into the same group or under a centralized coordinator. To summarize, this first prior art approach does not provide a mechanism for effectively managing a collaborative business process between different enterprises.
In a second prior art approach, electronic commerce (E-Commerce) applications or agents cooperate through message exchanges or conversations. An example of such an approach is described by the Foundation for Intelligent Physical Agents (FIPA) in a publication entitled, “FIPA97 Agent Specification,” (see http://www.fipa.org/). Unfortunately, the second prior art approach has difficulties in modeling inter-enterprise business collaborative business processes.
One difficulty is that businesses typically collaborate by following certain rules or protocols, such as “if you send me a price request then I will send you a quote”, and “if the quote I sent you is acceptable, then you will send me an order”. Furthermore, these rules or protocols typically include sequences of steps, where some of those steps are nested. Consequently, these rules are difficult to manage with simple messages or conversations utilized by this prior art approach. Moreover, many real applications include complex business processes that have a number of concurrent, long-duration, nested tasks, which are difficult if not impossible to manage and trace through flat conversations.
Other approaches provide interfaces that may be utilized by parties, who wish to interact. An example of this approach is defined by the RosettaNet Consortium that was founded in 1998. The consortium defines standard interfaces between partners for business process integration. More specifically, the consortium is developing Partner Interface Processes (PIPs) that define the processes and data elements necessary for a broad set of supply chain scenarios. Unfortunately, these approaches do not provide an infrastructure for implementing the business process, nor do these approaches provide an execution model or strategy. For example, these approaches do not specify how partner process instances are synchronized or made to be aware of the progress of other processes.
Workflow Management
Workflow management is a rapidly evolving technology that many businesses in a variety of industries utilize to handle business processes. A business process, as defined by the Workflow standard—Terminology & glossary, Technical Report WFMC-TC-1011, Workflow Management Coalition, June 1996. Versions 2.0, is simply a set of one or more linked activities that collectively realize a business objective or a policy goal, typically within the context of an organizational structure defining functional roles and relationships. A workflow is defined as the automation of a business process, in whole or in part, during which documents, information, or activities are passed from one participant to another, according to a set of predefined rules. A workflow management system (WfMS) defines, creates, and manages the execution of workflows.
Conventional workflow systems are primarily designed for intra-enterprise process management. The general function of a workflow engine is to support the modeling and execution of business processes. Conventional workflow systems use a single server to schedule the tasks of the business process. Although the tasks that contribute to a process can be distributed, all tasks are centrally scheduled at the process level.
Such centralized process control may be appropriate for a single enterprise. However, centralized process control is not appropriate for business processes between partners in different enterpirses since intra-enterprise process management and inter-enterprise process management are significantly different.
When multiple parties, belonging to different enterprises, are involved in a business process, these parties are unlikely to use a centralized process management because they are often separated by firewalls, have self-interests, or do not wish to share all the process data. For example, it is unrealistic to have a buyer and a seller coordinated by a single workflow engine. Moreover, it is unreasonable for the buyer and seller to place their private data (e.g. negotiation threshold) into the common process data packet for flow control.
However, these parties need support for peer-to-peer interactions. The lack of such support is a major impediment for using conventional centralized workflow systems for inter-enterprise E-Commerce automation.
Based on the foregoing, there remains a need for a method and system for a mechanism to support collaborative business processes that involve players in different enterprises and that overcomes the disadvantages set forth previously.